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A he working day shall last eight 
hours." What fool was responsible for 
that gem? Actually, it was the automo- 
tive engineer Robert Bosch (1861-1942) 
in a speech on work rules back in 1906. 
The workweek at that time consisted of 
six 10- to 12-h workdays. Bosch wanted 
to bring relief to his workers. We haven't 
seen much change since then. In fact, for 



day often lasts longer than eight hours. 

Today, most of us associate the Bosch 
name with automotive systems. The 
automotive technology division of the 
Bosch Group has continually been at 
the forefront of system improvements. 
It specializes in fuel injection and man- 
agement, chassis systems (e.g., antilock 
brakes and electronic stability), and 
energy and auxiliary systems (e.g., 
starters and alternators). And let's not 
forget Blaupunkt audio gear and tons of 
semiconductors and control units. 

The result of the Bosch dynasty has 
been the proliferation of electronics in 
automotive design. The growth in cop- 
per wiring harnesses has exploded like 
subway lines extending deep into grow- 
ing suburban communities. To reduce 
copper usage and the added weight to a 
vehicle, the Bosch team pared down the 
automobile's unwieldy umbilical cord by 
replacing it with an interconnecting bus 
to time-share control and status informa- 
tion. This was a huge change in the way 
engineers thought about system design. 
Today, many of the new vehicles on the 
market have multiple buses. 

CONTROLLER AREA NETWORK 

It's common to reference the seven- 
layer open system standard (OSI) — devel- 
oped by the International Organization 
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for Standardization (ISO) in 1984 — when 
discussing a network (see Figure 1). Each 
layer defines a stage that data passes 
through when traveling from one 
device to another over a network. 

The seven layers are separated into two 
sets: application and transport. Specific 
protocols may combine multiple layers 
as in the CAN protocol. The CAN 
specification (ISO 11898) combines the 
data and physical layers of the OSI. The 
data link sublayer has two responsibil- 
ities: logical link control (LLC) and 
media access control (MAC). Together 
they construct the message format. 
The physical sublayer specifies the 
physical and electrical characteristics 
of the bus used to transmit message 
characters between nodes. 

The hardware implementing the CAN 
bus may be electrical (single wire, twist- 
ed pair, or even wireless) or optical (fiber), 
and isn't defined by the specification. 
However, the physical signal encoding 
(non-return to zero, or NRZ), bit timing, 
and synchronization is totally defined. 
NRZ encoding defines a bit as a logic 
level and a 1 bit as a logic 1 level (see 
Figure 2). This differs from Manchester 
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Figure 2— The two most widely recognized ways a bit 
state can be defined is by a constant logic level at 
. some sample time (e.g., a non-return to zero (NRZ)) 
or a change of state (rising or falling edge) at some 
sample time (e.g., Manchester coding). Although 
Manchester offers convenient edges to synchronize on, 
it can require twice the bandwidth of NRZ. 
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Figure 1— These seven layers represent a conceptual 
framework for implementing communications across a 
network. Many protocols will cover multiple layers. The 
CAN protocol covers both the data link and the physi- 
cal layers as defined by IS011898. 

encoding, where a bit is a logic 0-to-l 
change, and a 1 bit is a l-to-0 change. 

Manchester encoding has the advan- 
tage of providing at least one edge/bit 
from which periodic clock synchroniza- 
tion can be extracted. NRZ encoding can 
pass more data per transition (which usu- 
ally limits bandwidth) so it can be more 
efficient. As you can imagine, NRZ data 
consisting of numerous or 1 bits would 
fail to change states. All asynchronous 
communicating devices must be able to 
synchronize their receiver clocks to the 
data being transmitted. Without any 
edges (changes in data state), this can't be 
accomplished. 

Bit stuffing is implemented to guaran- 
tee an edge every 5 bits. The bit-stuffing 
rule simply defines that if any transmit- 
ted data remains constant for five bit 
times, an extra bit of the opposite polarity 
is automatically added to (stuffed into) 
the transmitted data. At the other end, if 
received data remains constant for five 
bit times, the next bit is tossed out. 

Asynchronous serial data is normally 
unidirectional in nature. A single source 
provides data. The CAN protocol uses 
carrier sense multiple access with col- 
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l (CSMA/CD). Every CAN 
node must monitor the bus for no activity 
before transmitting. This allows any 
node to act as a producer of data, while 
other nodes are the consumers of data. 

Collision detection allows nodes to per- 
form nondestructive bitwise arbitration. 
This arbitration requires all of the trans- 
mitters to listen to the bus while they're 
transmitting. Think of logic 1 as recessive 
and logic as dominant. If a node outputs 
a (dominant), the bus will reflect this 
fact (read as a 0). If a node outputs a 1 
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Figure 3— In typical asynchronous communication, a bit's logic 
level is sampled somewhere around half (in the center of) the 
bit time. The nominal bit time of an asynchronous CAN commu- 
nication uses a slightly different calculation for determining the 
sample point. There is a propagation delay associated with the 
sample point such that a node at one end of the bus must be 
able to respond to a node at the opposite end of the bus before 
the sample time. 



(recessive), the bus will reflect this fact 
(read as a 1 ) unless some other node is 
dominating by outputting a 0. The CAN 
protocol requires a recessive node to back 
off and give way to the dominant node. 

For this to work properly, the bit's sam- 
ple point must be positioned correctly 
within the bit. In normal serial commu- 
nication, a bit is sampled somewhere 
around half of the bit time. A propagation 
delay time is added to the CAN's sample 
point calculation (see Figure 3). The prop- 
agation delay time allows for a dominant 
state from a distant node to reach 
a recessive node. So, basically, a 
sort of hierarchy of importance is 
established on the bus by assigning 
lower dominant values to those 
nodes with higher importance. 

The frame sends data. The CAN 
protocol defines four frame 
types: data (Here is my data), 
remote (Please send this data), 
error (I detected this error), and 
overload (Hold on, I'm not 
ready). Figure 4 shows the 
arrangement of data within each 
of the four frame types. 



The data frame has the remote trans- 
mit request (RTR) bit cleared, and the 
remote frame has the RTR bit set. 
Otherwise, the format of each is identi- 
cal. The areas of concern to the user 
within these frames are the arbitration 
field, the control field, and the data field. 
While the 11 -bit identifier has an inher- 
ent bus priority associated with it, it is 
also used by a receiving node's message 
filtering to determine if the message 
needs to be processed or neglected. Note 
the identifier extension (IDE) bit located 
right after the RTR bit. If this bit is set, 
the 18-bit extended identifier is expected 
prior to the control field. 

In systems where the 11 -bit identifier 
isn't sufficient, the arbitration field can 
be expanded to 32 bits if desired. This 
would be true for both the data and 
remote frames. Note that arbitration 
between a node using the standard data 
frame and another node using an extend- 
ed data frame with the same 1 1-bit iden- 
tifier is won by the standard data frame 
(IDE=0 is dominant). 

The control frame's data length code 
bits indicate the number of data bytes 
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(up to eight) that follow in the data field. 
A 15-hit CRC field follows the data field 
to aid in determining transmission 
errors. After the CRC field, there's an 
ACK bit. Receiving nodes confirm cor- 
rect reception by applying a dominant 
in this bit. The protocol handles all of 
the packet building and checking. You 
supply information for the identifier, 
control, and data fields, and the CAN 
protocol does the rest. 

Between each data and remote frame is 
a mandatory inter-frame space, which is 
essentially bus idle time. However, it also 
allows the two other frames to be used. 
They're pretty much the same in format, 



as you can see in Figure 4. Any node that 
detects an error in reception can indicate 
such by waving dominant bits onto the 
inter-frame space. This in itself is an error 
in the protocol, and all nodes will respond 
with error frames. The sender can take 
the appropriate action (retransmit). The 
overload frame will do much the same 
thing. Although its purpose might be to 
delay frames, this is essentially a vio- 
lation of the bit-stuffing rule. 

CAN TRANSCEIVERS 

The CAN specification describes the 
recessive/dominant communications 
between nodes. It doesn't specify the 
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Figure 4— The four types of CAN frames defined in this protocol are: data frame (a), remote frame (b), error frame (c), and overload 
frame (d). An inter-frame space is expected after each data and remote frame (e). This provides time for error and overload frames to be 
recognized. The extended identifier is optionally supported by CAN 2. OB (f). 



particular parts used to accomplish this. 
This circuitry can vary depending on the 
transmission medium (electrons versus 
photons). You may be familiar with RS- 
485's use of a differential twisted pair 
bus. These drivers can handle long cable 
runs, and they offer immunity to noisy 
environments because of the differential 
twisted pair. The problem with this 
hardware is that it doesn't support mul- 
tiple nodes outputting opposing states 
on the bus. So, RS-485 drivers can't be 
used in a CAN environment. 

Figure 5 (p. 76) shows how a typical 
CAN transceiver differs from the RS-485 
drivers. A logic 1 and input to a RS-485 
device drives output 
levels hard in opposite 
directions to a 5-V differ- 
ential voltage. In a CAN 
device, a logic 1 input 
doesn't drive the output, 
but it allows both out- 
puts to float to approxi- 
mately 2.5 V, the bus's 
nominal bias level and 
recessive state. A logic 
on the input drives the 
CANH output high and 
the CANL output low 
(the dominant state). 

The slew speed of the 
outputs can be controlled 
via the RS pin. You may 
want to adjust this slope 
control based on line 
length and speed to opti- 
mize noise rejection, 
Because safety is a 
concern on a bus where 
any transceiver could 
cause a total failure of 
communications, the 
CAN transceiver has 
built-in dominant failure 
detection, Let's say a 
node failure causes the 
TXD to get hung low, 
leading to an extended 
dominant state. After 
approximately 1.25 ms, 
the transceiver will dis- 
able itself as long as 
the TXD remains low. 
Power-out and brown- 
out protection disables 
the transceiver as well. 
When using this twisted 
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Figure 5— While an RS-485 transceiver forces its differential outputs to 
logic states under both data conditions, the CAN transceiver can only 
pull its outputs in one direction. A logic high input disables any drive, 
allowing the outputs to float to half of V cc (recessive state). A logic low 
input drives the outputs to their high and low output levels (dominant 
state). This enables any node to dominate (win bus arbitration) another 
node that's outputting a recessive state. 



pair interface, the bus should be ter- 
minated to 120 Q at each end. 

Although no standard CAN connectors 
are specified, labeling and pin assign- 
ments are suggested for various connec- 
tor styles. Several connector styles are 
recommended: nine- and 15-pin D-sub, 

10 and RI-45, five-pin SIP, five- to 
12-pin round connectors, and the IEEE 
1394 (FireWire) connector. The style 
you choose may depend on the distance 
between nodes, environmental concerns, 
or simply what's necessary to mate to 
an existing bus. 

Assuming all this bottom-layer stuff 
has been implemented, what is actually 
necessary to communicate using this 
lower layer hardware? 

TRANSMISSION & RECEPTION 

Multiple manufacturers support CAN 
communications, even in low-pin- 
count microcontrollers like Atmel's 
AT89C51 and Freescale's MC68HC08. 
Microchip took an interesting tack in 
implementing a CAN controller. It 
developed a CAN peripheral off micro- 
controller that uses a SPI to interface to 
any microcontroller. Not only is this a 
less expensive development project, 
but it also has the benefit of allowing 
any processor to take on the CAN 
bus. The Microchip MCP25 15 consists 
if a total CAN engine including two 
receive buffers and three transmit 
buffers complete with filters and 
masks (see Figure 6). 



What are masks and fil- 
ters, and how are they used? 
Earlier I explained that you 
have access to CAN data 
consisting of control stuff 
(an 11 -bit identifier and 
18-bit extended identifier, if 
used) and up to 8 data bytes 
(14-byte buffer). When a 
CAN message has been 
received and CRC verified, 
it leaves the protocol engine 
and is transferred to the 
message assembly buffer 
(MAB). At this point, it waits 
to be transferred to one of 
the two receive buffers. 

Not every message 
received by a node is nec- 
essarily of interest to that 
node. A mechanism to 
reject unnecessary messages keeps the 
workload down to a reasonable level. 
This mechanism consists of a set of 
mask and filter registers for each receive 
buffer. Each mask consists of four regis- 
ters. Each filter consists of four registers. 
These registers are associated with the 
11 -bit identifier field and either the 
18-bit extended identifier field (IDE 
bit-1, if used) or the first 2 data bytes. 
The mask registers identify bits of 



importance. Let's say that a system is 
made up of numerous nodes, each with 
two digital input bits (an On button and 
an Off button). One node has a digital 
output bit that controls a light. Every 
node with push buttons could send a 
change-of -state flag via the 1 1-bit identifi- 
er's LSB and data about this change. The 
node that controls the fight's state need 
only pay attention to those messages that 
have commands from nodes with push 
button status information. By placing a 1 
in the LSB of the identifier's position in 
the mask register (with all other bits as 0), 
you've indicated that only this bit is of 
any significance. 

The filter registers determine the logi- 
cal state of interest for any significant 
bits. In this case, only the 11 -bit identifi- 
er's LSB in the MAB is compared to its 
corresponding bit in the filter register. A 
match of these enables the MAB's con- 
tents to be moved into the associated 
receive buffer. Otherwise, the message is 
discarded. With these simple tools, this 
node will receive only the messages in 
this buffer that may affect the state of its 
output. A totally different mask and filter 
can be used to restrict messages for the 
second receive buffer. It's up to you to 
determine from the received data if action 
is necessary. This data may contain fight 
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Figure 6— The CAN controller contains two distinct areas, 
buffers are provided for data coming and going, 
needs any processing. 



data buffers and the protocol engine. Separate 
determine if a received message 
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Photo 1— CAN nodes available from Diversified 
Engineering provide a good platform for experimenting 
with or developing your own CAN-based applications. A 
preprogrammed CAN application (with source code) 
lets you investigate node communications immediately. 

level information or an instruction for a 
timer to keep the light on for 1 min. 

Sending a CAN message doesn't 
involve any masks or filters. You're 
responsible for setting up the 14-byte 
buffer registers properly. This includes 
the identifiers, control, and data bytes. 
Multiple transmit buffers (three) allow 
messages to be cued up for transmission 
or each transmit buffer set to send some 
standard response or request. The priority 
of these buffers can be configured to force 
the order in which multiple enabled mes- 
sages get sent. Even though the CAN pro- 
tocol will handle errors and automatically 
resend messages, individual transmit 
buffer errors can be monitored. 

CAN EDUCATION 

There is nothing like playing with real 
hardware to shed light on those hazy 
areas of operation. Diversified Engineering 
has been supporting Microchip's PIC 
micros and the CAN interface for years 
now. It offers a number of CAN modules 
that you can use to develop your own 
CAN system and some courseware to get 
you started (see Photo 1). I used an oscil- 
loscope on Diversified Engineering's Qik 
Start CAN-NET Education Board to 
look at some real CAN messages. It 
came preprogrammed with a simple 
CAN-NET application. 

Photo 2-shows bit stuffing used by 
the CAN protocol engine to ensure that 
some logic level transitions take place 
after sending five sequential data bits of 
the same polarity (an 11-bit identifier of 



0x000 is being sent). Although 
the actual length (total message 
bits) of a CAN transmission 
may vary as a result of bit stuff- 
ing, a maximum data length of 
8 bytes ensures that CAN mes- 
sages are short. This particular 
request message requires less 
than 500 us of bus time. 

In Photo 1, the larger node 
incorporates a bunch of I/O (a 
keypad, LCD, and a serial port) 
in its CAN implementation. In 
Stand- Alone mode, the LCD 
can display the 2-byte data 
associated with any of the 
identifiers selected via the key- 
pad. The serial port outputs all 
CAN bus messages to a PC run- 
ning Diversified Engineering's 
free CANMan bus monitor pro- 
gram. This program allows you 
to set mask and filter values to 
limit which messages the moni- 
tor receives. Also, you can send 
a CAN message directly from the moni- 
tor. This is great for when you're devel- 
oping CAN modules. 

Diversified Engineering's CAN mod- 
ules make use of Microchip's stand-alone 
MCP251x CAN controller. The success 
of this viable CAN peripheral naturally 
led to the inclusion of this controller as 
an internal peripheral to some devices in 
the PIC18F series of microcontn 




CAN REVISIONS 

Like any good specification, the CAN 
protocol continues to evolve. Version 2.0 
specifications are divided into parts A and 
B. There is one basic difference between 
these two parts. Part A is the original pro- 
tocol that uses the standard 11 -bit identi- 
fier followed by a control field beginning 
with two reserved bits. Part B redefines 
the first reserve bit as an IDE indicator 
and goes on to define the extended identi- 
fier field. Originally a reserved bit, early 
CAN engines should accept a frame find- 
ing this reserved bit recessive. However, 
the extended identifier that follows won't 
fit the expected format. Therefore, CAN 
devices may be rated according to their 
adherence to the present specifications. 

The minimum acceptable rating would 
be CAN 2.0A (i.e., conforms to the proto- 
col's original 11 -bit identifier). A CAN 
2.0B rating may be active or passive. 



Photo 2— The sequence seen here is the beginning of a CAN 
message with an identifier of 0x000. Bit stuffing is used to ensure 
an edge at least once every five bit times. In this oscilloscope shot, 
you can see that beginning with the SOF. A 0x000 identifier has a 
bit of (in this case) a recessive state stuffed into the data transmis- 
sion after each five unchanging (in this case dominant) bits. The 
CAN protocol engine automatically removes these at the opposite 
end. It shows a recessive bit stuffed after the five dominant bits 
(SOF and ID bits 10 through 7). Another recessive bit is stuffed 
after the five dominant bits (ID bits 6 through 2). One more reces- 
sive bit is stuffed after the five dominant bits (ID bits 1 through 0, 
RTR, IDE, and RB0). . 



CAN 2.0B passive devices wouldn't choke 
on extended identifier messages (cause 
message errors); however, they wouldn't 
process them. A CAN 2.0 active device 
fully supports messages using standard 
and extended identifiers. It's recommend- 
ed that all new devices conform to 
CAN 2.0B passive as a minimum. H 

Jeff Bachiochi (pronounced BAH-key- 
AH-key) has been writing for Circuit 
Cellar since 1988. His background 
includes product design and manufac- 
turing. He may be reached at jeff. 
bachiochi@circuitcellar.com. 
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Can You Speak CAN? (Part 2) 

A Look at CANopen 

Last month, Jeff introduced some of the new CAN modules on the market. This month, he 
describes the advantages of using the higher-level CANopen protocol. 



hether you've chosen to use the 
CAN communication interface for its 
multimaster capability, inherent noise 
immunity, transparent transmission han- 
dling, priority messaging, or any combi- 
nation of these and other advantages, you 
end up with a serious question left unan- 
swered. While the CAN interface defines 
the bottom tiers of the seven-layer OSI 
standard for networks, this hardware will 
most likely need some embedded code to 
define the upper tiers of the standard, no 
matter how simple it is. Even in the 
simplest of systems, you'll need to define 
the data's form when it is transmitted. 

One of the advantages of the CAN bus 
is the ability of a node to simply pass its 
data to the bus. Because all the nodes can 
monitor this information, the data does 
not have to be passed to every node that 
might use it. In fact, the transmitting 
node doesn't have to know who else is 
out there. Ekminating node-to-node traffic 
reduces bandwidth requirements. 

If your nodes will be used with other 
CAN nodes, all bets are off. You'll need 
to adhere to the rules already imple- 
mented by the nodes on the bus. The 
bottom line is that if you have total 
control, go ahead and define your own 
upper-level protocol. However, you 
might want to consider using one of the 
already established CAN protocols. 

HIGHER-LEVEL PROTOCOLS 

CANKingdom was developed specifi- 
cally for machine control, while other 
protocols are more focused on factory 
automation. Among other things, CAN- 
Kingdom supports hot swaps in a safe 
manner. It also supports dynamic change 
of identifiers, a global clock, module iden- 



tification by EAN/UPC code, Std and Ext 
identifiers, and a hardware-only limited 
number of modules in a system. CAN- 
Kingdom allows other protocols to be inte- 
grated into a CANKingdom system, usu- 
ally with a loss of system performance. 

In the early 1990s, the Society of Auto- 
motive Engineers (SAE) Truck and Bus 
Control and Communications Subcom- 
mittee started to develop a CAN-based 
application profile for in-vehicle commu- 
nication in trucks. Today, the SAE's 
J 1939 standards family is the preferred 
HLP for equipment used in numerous 
industries (e.g., marine and construction). 

DeviceNet is used mainly in industrial 
applications (factory automation in par- 
ticular). It's a low-cost communications 
link used to connect industrial devices 
(e.g., limit switches, photoelectric sen- 
sors, and operator interfaces) to a net- 
work and to eliminate expensive hard 
wiring. The Open 
DeviceNet Vendor Asso- 
ciation (ODVA) devel- 
oped the internationally 
standardized DeviceNet 
specifications. When you 
buy the DeviceNet speci- 
fication, you receive an 
unlimited royalty-free 
license to develop 
DeviceNet products. 

CANopen was devel- 
oped as a standardized 
embedded network with 
highly flexible configura- 
tion capabilities. It was 
originally designed for 
motion-oriented machine 
control networks such 
as material-handling 



systems. Now it's used in medical 
equipment, off -road vehicles, maritime 
electronics, public transportation, and 
building automation. 

CANopen provides standardized com- 
munication objects for real-time data 
(process data objects, or PDO), configura- 
tion data (service data objects, or SDO), 
special functions (timestamp, sync mes- 
sage, and emergency message), and net- 
work management data (boot-up mes- 
sage, NMT message, and error control). 
Some CANopen specifications (draft 
standard) are free. CAN in Automation 
(CiA) membership is required to down- 
load work drafts. 

It is reassuring to know that the hard- 
ware you may have designed can be used 
with any protocol, provided the embed- 
ded processor you've chosen has the 
application space to support the protocol 
of choice. Using a small microcontroller 



COB ID 


Communication objects 


Comment 


0x000 


NMT Services 


From NMT master 


0x080 


Sync message 


From SYNC producer 


0x081 -OxOFF 


Emergency message 


From nodes 1-127 


0x100 


Timestamp message 


From timestamp producer 


0x181-0x1 FF 


First transmit PDO 


From nodes 1-127 


0x201 -0x27F 


First receive PDO 


For nodes 1-127 


0x281-Ox2FF 


Second transmit PDO 


From nodes 1-127 


0x301 -0x37F 


Second receive PDO 


For nodes 1-127 


0x381 -0x3FF 


Third transmit PDO 


From nodes 1-127 


Ox401-Ox47F 


Third receive PDO 


For nodes 1-127 


0x481-0x4FF 


Fourth transmit PDO 


From nodes 1-127 


0x501 -0x57F 


Fourth receive PDO 


For nodes 1-127 


0x581-0x5FF 


Transmit SDO 


From nodes 1-127 


0x601-0x67F 


Receive SDO 


For nodes 1-127 


0x701 -0x77F 


NMT error control 


From nodes .1—127 



Table 1 — This is the predefined list of CANopen COB IDs. Functions that 
include a node (1-127) have individual COB IDs for the node. For instance, 
an emergency message from node 5 has the COB ID 0x085 (0x080+5). 
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may eliminate the possibility of imple- 
menting certain protocols. If a protocol's 
minimum requirements can't be support- 
ed based on the available memory (both 
code and data space), you're out of luck. 

DESIGNING FOR CANopen 

Last month, you learned that the CAN 
message data frame was basically made 
up of an 11 -bit identifier field, a control 
field (which among other functions could 
extend the identifier to 29 bits), a data 
field (containing up to 8 data bytes), a 
15-bit CRC checksum, and a message 
acknowledge. An interframe space pro- 
vides time for overload and message 
frames to interact with data frames. The 
CAN protocol engine handles this in a 
way transparent to the user; however, it's 
handy to know how this works because 
the frame fields are part of the software 
interface the higher level protocol must 
deal with to be able to communicate 
through the CAN bus. 

How a higher-level protocol makes use 
of the CAN message's identifier field is 
really the basis of the protocol. Remember 
that any node may produce a CAN mes- 
sage frame at any time. Frames that occur 
simultaneously must win the bus through 
arbitration. The message sent with the 
lowest (value) identifier has the highest 
priority and gets to finish its message 
frame. The loser must wait and try again. 
So, the value of the identifier indicates its 
importance regarding message priority. 

The CANopen standard uses a connec- 
tion object (COB) ID to define message 
functions. Table 1 shows the predefined 
set of COB IDs. The CANopen standard 
has room for 127 nodes. Although data 
traffic doesn't need to know which nodes 
are on the bus because they generally 
don't use node-to-node communications, 
each node does have its own COB ID that 
can be used to identify it. Let's take a look 
at each of the COBs to see how they're 
used within the CANopen protocol. 

NMT SERVICES 

CANopen nodes connected to a 
CAN bus are entities on that CAN 
network. Their node numbers can 
individually identify them. However, 
when necessary, all nodes can receive 
a network message from a network 
master or maintenance program used 
to configure nodes on the network. 



As you can see in Table 1, an NMT 
message has a COB ID equal to 0x000 
(11-bit identifier). This special message 
contains a data field using only 2 bytes. 
The first byte contains command infor- 
mation; the second byte identifies whom 
it's for. If the second byte is 0x00, it's for 
everyone; otherwise, the byte holds the 
intended recipient (nodes 1-127). 

There are five available NMT com- 
mands: 0x01 (switch to Operational 
mode), 0x02 (switch to Stopped mode), 
0x80 (switch to Preoperational mode), 
0x81 (reset), and 0x82 (reset communica- 
tions). You can see how these commands 
might be used to put a node (or the 
entire network) in a particular state. A 
CANopen node must be capable of recog- 
nizing all NMT commands and following 
a general state model (see Figure 1). 
Because the NMT COB ID has the low- 
est possible value, its message has the 
highest possible priority. 

NMT ERROR CONTROL 

At the opposite end of the priority level 
is the NMT error control object, which 
has two uses. It's used as a boot message 
when a node transitions from initializa- 
tion to preoperational modes, and it's 
used as the heartbeat message. In both 
cases, the message frame includes a single 
data byte containing the state (mode) 
of the node. Heartbeat messages can be 
either requested by a master node (node 
guarding) or, more preferably, configured 
to periodically broadcast its presence. 

Note that the value of the state used in 
the message differs from the value sent 
by an NMT service command. It reflects 
the present state and not a requested one. 



Power-on 




Reset 


reset 







| initialization j - 



Transmit 
boot message 

T 




Figure 1— A CANopen node should follow this general 
state diagram so that it will transition properly from an 
NMT service request. This provides node control via the 
network for configuration purposes. 
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SYNC MESSAGE 

A SYNC message has no data bytes 
associated with it. The message, which 
is sent by one node, indicates a point 
in time when all nodes (watching for 
it) should simultaneously sample and 
respond with their data. The SYNC 
producer knows that this data defines 
the data at an instant in time no matter 
when the data is actually received. This 
method of gathering data is preferable 



EMERGENCY &TIMESTAMP 

You might have noticed that the 
emergency message uses a similar COB 
ID range. Although the SYNC message 
has no node ID associated with it, the 
emergency message references the node 
reporting the emergency. The message 
has at least 3 data bytes. The first 

2 bytes denote a predefined error code. 
The third byte is a copy of the error reg- 
ister (located at index 0x1001, subindex 
0x00). The remaining five optional bytes 
are manufacturer-specific. Note that an 
error is reported just once, unless the 
report is a reset of the error condition 
(first data byte=0x00). 

A timestamp message is similar to a 
SYNC message. It's simply sent to all 
nodes indicating the time of day. A 6-byte 
data message consists of 3 bytes in mih 
liseconds of the time since midnight and 

3 bytes in days since January 1, 1984. 

CANopen SPECIFICS 

Let's get to the nitty-gritty of the 
CANopen protocol, which includes a 
method of accessing all of a node's infor- 
mation via the service data object (SDO) 
communication object. In addition to 
this method, it also includes a shortcut 
method for accessing multiple data ele- 
ments in a single process data object 
(PDO) message. To understand these, let's 
back up a bit and look at the concepts 
involved. Although you'd begin a discus- 
sion of most higher-level protocols with 
this, I believe that looking at the messag- 
ing format (discussed above) will help to 
put the following in the proper context. 

As a design engineer, it is imperative 
to have access to a datasheet for each part 
"ou are attempting to use. The datasheet 
Jt only describes the physical dimen- 
sions and connections, but also how it 
behaves electrically (or mechanically). 



Suppose that the temperature sensor 
you're using has an output of 10 mV/°C. 
If that part were to become scarce, you 
could make use of another part even if 
it isn't identical. For instance, a sensor 
with a 10 mV/°F could be used by just 
changing the calculations used 
along with the data. 

The CANopen protocol uses 
an object dictionary in each 
node to describe all of the 
processes and communications 
possible with it. This consists 
of a table of 65,536 possible 
entries, each with an 8 -bit 
subentry. This will most likely 
raise an eyebrow in a discussion 
of embedded controllers. It's 
important to note that every 
table entry is not required, and 
unused entries are not imple- 
mented. This significantly 
reduces the table size. 

The object dictionary is organ- 
ized in sections (see Figure 2). 
AH dictionary entries are used to 
locate data associated with the 
entry and indicate how that data 



is stored (by data type). This gives each 
node a way of presenting information 
about itself via exploration. A typical dic- 
tionary might be a look-up table of 6-byte 
entries. Each entry would begin with a 
2-byte index (dictionary object) followed 







Index 


Data type 






0x0001 


BooiSHn 


Index 


Description 










0x0002 


Integer 8 








0x0000 


Reserved 




0x0003 


Integer 16 










0x0001 -0X025F 


Data type 

■el 




0x0004 


Integer 32 


OX0260-OXOFFF 


Reserved 




0x0005 


Unsigned 8 


V 


0x0006 


Unsigned 8 




Communication 
profile 






0x1 000-0x1 FFF 




0x0007 


Unsigned 8 


0X2000-0X5FFF 


Manufacturer- 
specific 




0x0009 


Visible string n 








0x6000-0x9FFF 


Standardized 
device profile 






OxAOOO-OxBFFF 


interface profile 






OxCOOO-OxFFFF 


Reserved 







Figure 2— The object dictionary is divided into various sections. 
Many data types are fixed; however, there is a mechanism in place 
for describing other data types like extended and complex. When a 
dictionary entry refers to the data type, the value present identifies 
the type of data being listed. The data may be a standard data type 
or a manufacturer-specified data type. 
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by a 1-byte subindex 
(subobject). These 
3 bytes identify a partic- 
ular dictionary object. 
The fourth byte, the 
data type, describes the 
format of the dictionary 
object's data pointed to 
by the last 2 bytes. 

The first section in 
the dictionary has to do 
with data types and 
deals with identifying 
how data is stored. 
There are several pre- 
defined standard data 
types like Boolean and 
8-bit integer. When data is referred to, 
it has a data type associated with it. For 
instance, if the data type 0x02 is used, 
its information will be in an 8-bit inte- 
ger data format. Because this first sec- 
tion is predefined, it isn't mandatory. 
Although the protocol predefines many 
data types, special data formats can be 
defined in this section. A table entry 
here would associate a data type value 
with a format description of data that 
is stored elsewhere. 

In the second section, the communica- 
tion profile defines all of the special quali- 
ties of this node (see Table 2). The first 
entry, the device type, references a docu- 
ment that defines all of the specific infor- 
mation necessary to use the node. The 
referenced document is selected from 
one of many predefining different 
device profiles, such as battery chargers, 
encoders, and motor drives. The error 
register I covered earlier is located here. 
This mandatory entry of data type 0x05 
(1 byte) reflects the pres- 
ent general state of the 
node (0 = no errors). 

The NMT entry at 
0xlF80 allows a node to 
automatically go into 
Operational mode with- 
out waiting to receive 
an NMT command to 
do so. This is an impor- 
tant addition to the 
CANopen standard 
because many small sys- 
tems may not need any 
network configuration. 

Any node can be a 
producer of heartbeat 



Index 


Subindex 


Index description I Subindex name 


Data type 




0x00 








0x00, 


Error register 




0x1008_ 


0x00 


Device name (recommended) 




0x1016 


0x00 


Heartbeat: Time 

(Only if consumer, then one 
entry for each producer) 






Oxnn 


Time in milliseconds for 

node (nn=0x01-Ox7F) 




Oxl3l7~ 


0x00 


Heartbeat: Time 
(only if producer) 






"oxioiT" 




Identity object 


Number of entries 




0x01 


Vendor ID 




0x1F8O~ 


oxob 


NMT Startup 





Table 2— The device type (like the data type) is selected from a predefined list. These are acta 
ally documented profiles of devices that are presently going through or have previously gone 
through the development process as a CANopen device standard. Additional communication 
entries are necessary to describe the I/O for each specific device type. Only the mandatory 
communication entries are shown except where noted. 



messages. This is a periodic message pro- 
claiming the node's state. Any node 
that keeps track of other nodes' heart- 
beats is a consumer. It's responsible for 
taking the appropriate action should a 
node fail to produce a heartbeat message. 

Last month, I discussed the process of 
registering for a vendor ID. The commu- 
nication profile has an entry location for 
this ID. It's the only mandatory entry in 
the identity object. The subindex 0x00 
identity object entry has a data type 0x05 
(1 byte) that's similar to an error register. 
In this case, it identifies how many 
subindex entries are available. It uses a 
data value of 1, indicating one subindex. 
The vendor ID uses a data type 0x07 
(4 bytes). Other optional subentries avail- 
able in the identity object include your 
product code (subindex 0x02), revision 
number (subindex 0x03), and serial 
number (subindex 0x04). Using these 
would include changing the value of the 
subindex 0x00 (number of subindexes). 



1 Index des cription I Subindex name 

MBBM 




DOB ID used by PDO 



imber of entries 



DO Mapping of object #1 

mm 




Table 3— A generic I/O device that implements I/O functions requires these additional communica- 
tion entries. In this case, they may be digital or analog. 



Let's take a look at a 
generic I/O device to see 
which other parameters are 
required with this specific 
device type. The entry for a 
generic device type holds 
important information. As 
you can see in Table 3, the 
device type is an unsigned 
32-bit entry (4-byte) entry. 
The two least significant 
bytes indicate the device 
profile number (in this case 
0x0401, document DS401). 
The lower 4 bits of the next 
most significant byte indi- 
cate any I/O that's imple- 
mented on the device: bit 16 for any digi- 
tal inputs, bit 1 7 for any digital outputs, 
bit 18 for any analog inputs, and bit 19 
for any analog outputs. The most signifi- 
cant byte indicates special functions. 

In a generic device, there is presently 
one special predefined option: joystick. A 
one indicates implementation in the 
respective bit position. The rest of the bits 
are unused bits and reserved for future 
use. You can determine a lot about a 
device by simply looking at the entry in 
location 0x1000 of its dictionary. 

When a device supports any of the four 
aforementioned I/O types, additional 
entries are required for each I/O in the 
communication and in the device profile 
sections. The communication entries for 
inputs and outputs are similar and can be 
found at specific locations in each section. 
An output's definition is divided into two 
areas: the PDO data is packed into (begin- 
ning with the first output at location 
0x1400) and how the data is mapped into 
(positioned within) a 
message (at a corre- 
sponding location of 
0x1400 + 0x0200). 

As in most entries, the 
first subindex indicates 
how many subentries 
are associated with this 
entry. The COD ID is 
at subindex 0x01. This 
entry also uses the 
most significant bit to 
enable/disable the uses 
of PDOs. (Remember 
that PDOs are a way for 
a device to pack multi- 
ple data objects into a 



Data type 



0x05 
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single message, thereby saving band- 
width.) The last mandatory subentry 
indicates if the data is processed on a 
SYNC (which I discussed earlier) or 
asynchronously. 

The entry at index 0x1600 holds the 
actual mapping of the object in a PDO. 
Because the longest CAN message can 
transfer up to 8 bytes, a PDO can handle 
any combination of 64 bits. The subindex 
entry 0x01 is 4 bytes, indicating the 
index and subindex of where the data 
comes from and how many bits are used 
by this entry. A second output would 
We its own entry at subindex 0x02. 

Inputs are handled the same way as 
outputs beginning at the index location 
0x1800. Although it's just an optional 
parameter and shown only in the TPDO, 
both inputs and outputs have the ability 
to periodically send out a PDO message 
(a broadcast of the present data in the 
PDO). An entry subindex of 0x05 (at 
0xl40x or 0xl80x) has a value in mil- 



liseconds, which shows how often 
this should be performed. 

Using the object dictionary entries, you 
can determine the type of device being 
described. You can find information about 
any I/O the device supports and deter- 
mine how this data might be mapped into 
a single PDO message. Now additional 
information can be found in the device 
profile section of the object dictionary. 
This is the section that includes the loca- 
tion of the actual data (unmapped). The 
device profile section contains separate 
entries for each type of input and output. 

Digital inputs require two entries. The 
first entry at location 0x6000 indicates 
how many 8-bit subentries there are for 
this entry. The subentries hold the actual 
data in 8-bit format. The CANopen proto- 
col's flexibility is demonstrated in this 
section. Although it isn't shown in 
Table 4, the data can be accessed in a 
number of different formats. The generic 
I/O device format supports digital data by 



the individual bit, 8 bits, 16 bits, and 
32 bits. Table 4 shows only the 
mandatory registers for 8-bit access. 

A handy operation for digital I/O is 
to allow the polarity of the data to rep- 
resent either the true or the inverted 
state of the inputs or outputs. The 
polarity index location determines this 
action for each corresponding bit. Other 
optional locations allow for changing 
input data to trigger a CAN change of 
state (COS) message. Outputs have an 
optional error mode that can define 
how they react to an error. For example, 
when enabled, the error mode can use 
the error value to place all of the out- 
puts in a predetermined safe state. 

Analog data can be provided in many 
formats as well. In addition to the 8-bit 
format shown in Table 4, the 16- and 32- 
bit formats are also supported. Provisions 
are made for floating-point or a manufac- 
turer's specific format. Some scaling and 
offset factors are also available. Like the 
optional digital input COS function, an 
analog channel can produce messages 
based on its value compared to a number 
of parameters (<, >, =, and <>). Analog 
outputs also have the optional error 
mode associated with each output. 

SDO 

I already covered the COB IDs used in 
CANopen and how the predefined IDs are 
used to handle various communications 
activities needed with any higher-level 
protocol based on a communication stan- 
dard (the CAN interface in this case). I 
interrupted my description of PDO and 
SDO to describe the object dictionary (a 
table of various information). Knowing 
what's presented in this table should give 
you a clearer picture of just why you 
might need the SDO and PDO functions. 

Let's start with the SDO (see Table 5, 
p. 76). Note that there is a transmit and 
a receive SDO. These implement generic 
access to every dictionary object. Using 
the SDO (COB ID + node address), every 
node (plus any network management 
interface) has access to everything. A 
CAN message with a COB ID of the 
Transmit Service Data Object (TSDO) is 
requesting data from a particular node. 
A CAN message with a COD ID of the 
Receive Service Data Object (RSDO) is 
providing data to a particular node. SDO 
transactions use a request/response for- 




0x6410 

I 0x01 



Analog \ Write analog output 
output 




■ Number of 
-bit outputs 

Write Outputs 




Error value output -0x05^ 



.able 4— I/O data is stored at specific locations in the device profile section of the object dictionary according to 
the I/O function. All of the available functions are explained in a document standard (DS) referenced by the device 
type at location 0x1000 (see Table 2). A flexible system of operators can help format and manipulate data. 
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mat. Thus, every transfer requires two 
messages — a message to the TSDO or 
RSDO followed by the node's response — 
and could potentially hog bandwidth and 
time and should be used strictly for 
service data purposes. Enter the PDO. 

FIRST PDO 

The most obvious difference between 
the SDOs and the PDOs listed in the 
predefined COB ED set in Figure 1 is that 
there are multiple PDOs. This should 
give you a hint at their importance. Cer- 
tainly, CANopen allows the use of SDO 
request/response transfers to get I/O data. 

Let's suppose an I/O board has 
16 digital input bits, 16 digital output 
bits, two 8 -bit analog inputs, and two 
8 -bit analog outputs. To gather this data 
(based on the 8 -bit data 
format of Table 4), you 
need four separate SDO 
transfers (eight mes- 
sages) to complete the 
transaction. Using a 
PDO, all of the data can 
be mapped into one PDO 
location (a single mes- 
sage). The mapping of 
data shown in Table 3 
packs up to 64 bits of 
data in a single PDO. 
This data can be packed 
in various formats as 
long as it doesn't exceed 
64 bits (8 bytes). 

A node that monitors 
temperature, for 
instance, doesn't need to 
know which nodes (if 
any) require this infor- 
mation. It may set up its 
first TPDO to send out a 
message announcing the 
temperature periodically 
or on a 2° change in 
temperature. Every node 
that is interested in 
this data needs to 
somehow pay atten- 
tion to that Transmit 
Process Data Object 
(TPDO) to receive the 
information without 
having to ask for it. 
This makes for effi- 
cient use of the avail- 
able bandwidth. Any 



node can receive this data simply by 
redefining the COD ID of one of its 
Receive Process Data Objects (RPDO). 
Let's take a look at how this is accom- 
plished. 

You don't necessarily think of RAM 
when you think of a look-up table. But 
the basis of the CANopen dictionary is 
to use RAM so that entries (at least cer- 
tain ones) can be modified on the fly. 
Let's say that node 1 is reporting temper- 
ature in a message via its TPDO. It uses 
a COB ID of 0x181 to transmit a mes- 
sage of up to 8 data bytes of packed data. 

You may have noticed that the 
TPDOs and RPDOs have individual 
default locations, and a different one 
for each node. For other nodes to auto- 
matically receive and make use of the 



temperature information broadcasted 
by node 1, these nodes must have any 
of their RPDO COB IDs changed to 
0x181. This links TPDO 0x181 to 
those nodes implementing an RPDO 
0x181. Data originating at the temper- 
ature input on node 1 is automatically 
transferred into any node implement- 
ing an RPDO equal to the TPDO. In 
fact, the mapping of that RPDO also 
divvies up the packed data into specific 
I/O locations on that node. CANopen 
has tremendous flexibility. 

NETWORK MANAGEMENT 

If you manufacture two CAN nodes 
that are used exclusively on an internal 
two-node CAN network, you intimately 
node. And they can be stat- 




Table 5— SDO commands can transfer 4 data bytes using an expedited transfer (including the index and subindex) of the dictionary 
object being requested. When expedited, if segment transfers are supported, they may be used to speed up larger requests using a 
7-data-byte format. 
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ically configured (in the code) to work 
together without the need for any addi- 
tional network management. You have 
tierformed all the network management 
.ecessary for these nodes to live happily 
ever after. However, all bets are off 
when you want to add a third-party 
node. With some universal CAN 
widget, you must probe its dictionary 
objects to discover all of its secrets and 
change any object parameters (like the 
RPDO just discussed) to make it com- 
patible with the other nodes. 

Wouldn't it be easier if each node 
came with a datasheet? Well, the 
CANopen standard requires this. Dic- 
tionary objects along with their data 
comprise an electronic datasheet (EDS). 
Although a physical datasheet can be 
I via SDO probing, every manu- 
rer is required to provide a copy 
of its corresponding datasheet. This 
datasheet is an integral part of the con- 
formance testing in terms of EDS con- 
formance and device reflection. 

Even in the simplest of systems, it's 
likely there will be at least one node with 
some kind of upper-level management 
associated with it. It might be an embed- 
'ed node that simply monitors heartbeats 
and indicates a problem using an LED 
output. Or it might be a programmable 
logic controller (PLC) capable of extensive 
status reporting. When the configuration 
of a system exceeds what can be handled 
manually, network integration tools 
become necessary. 

Because much of the dictionary is 
RAM-based, CANopen configuration 
tools give you a means to configure 
each node dynamically in a way that 
integrates their functions with all of 
the other nodes in the system. Simu- 
lation tools can also help find defi- 
ciencies in the system's design before 
it's actually implemented in hardware. 

OUT OF SIGHT 

As designers, you must often make 
decisions about which direction to take 
when implementing a plan involving 
some communications between devices. 
Sometimes the advantages of employing 
a standard underlying technology like 
CAN makes sense. After you make that 

ap of faith, there are other challenges 
to confront. You'll need to create a data 
exchange format and determine how 



other problems will be handled. Why 
reinvent the wheel? 

You may have good reason to not use 
some higher-level protocols. This usually 
has to do with the minimum require- 
ments of those solutions. As a standard 
is tweaked to handle more possibilities, 
it can grow to unbelievable proportions. 
Just handling the minimum require- 
ments may not even fit into some micro- 
controllers. The CANopen protocol is 
powerful, yet the minimum require- 
ments allow it to be implemented in all 
but the smallest microcontrollers. Imple- 
menting it can open the door to a world 
of opportunity for your widget. Even if 
you are developing a system consisting 
of in-house devices, consider providing a 
path with a future. Get connected today 
and be ready for tomorrow. IS 

Jeff Bachiochi (pronounced BAH-key- 
AH-key) has been writing for Circuit 
Cellar since 1988. His background 
includes product design and manufac- 
turing. He may be reached at 
jeff. bachiochi@circuitcellar. com. 
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XOameStation 

Do-it-yourself video Game System 



Inspired by the 
Atari 2600, Apple II & 
Commodore 64! 




■Assembled XGS Micro Edition Unit! 
1 Complete Development Kit! 
Tools, Demos & Utilities! 
eBookon Designing the XGS Console! 
■Cables and Power Supply Included! 





www.XGameStatidn.cdm 

(925) 73S-209B SUPPDRT@NURVE.NET 



Buy a CAN interface 
for your PC! 



1 



USB 




• Windows, Mac OS X & Linux support 

• CAN monitor & software libs included 

• OEM ready (volume discounts) 

• USB 2.0 full speed 

• Powered from USB bus or external 

• CAN 11 & 29 bit ids, IMbit/sec 

Machine Bus Corporation 
www.machineBus.com 
866 864-8100 (toll free) 
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